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[57] ABSTRACT 

A packet of data is received from a LAN and transmitted 
over a WAN, by retaining the native LAN frame format of 
the packet during transmission across the WAN. Thus, LAN 
data may be transmitted over a SONET point-to-point link 
within a WAN network without the interim steps of creating 
ATM cells or other WAN transport packaging protocols. 
Instead, the LAN data may be transmitted directly over the 
SONET link as raw data, and reconstructed directly at the 
receiving end of the SONET link. A first buffer stores data 
from the LAN so that a corresponding packet size may be 
determined, and a second buffer stores data from the WAN 
to account for any speed difference between the LAN 
circuitry and WAN circuitry. 
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METHOD AND APPARATUS FOR 
TRANSMirnNG LAN DATA OVER A 
SYNCHRONOUS WIDE AREA NETWORK 

This is a continualioD-in-part of copending and com- 5 
monly owned U.S. Ser No. 08/681,313 filed on Jul 22, 
1996, ftom which priority is claimed and which is hereby 
incorporated by reference in its entirety. 

BACKGROUND OF THE INVENTION 10 

1. Field of the Invention 

This invention relates generally to computer networking 
systems and more particularly to transmitting data from a 
local area network over a wide area network. 15 

2. Discnsaon of the Related Art 

Computer networks are widely used to provide increased 
computing power, sharing of resources, and communica- 
tions between users. Local area networks (LANs) may 
include a number of computer devices within a room, 20 
building, or site that are connected by high speed data links 
such as token ring, ethemet, or the hke. LANs have tradi- 
tionally been interconnected by bridges, hubs, and switches; 
A Wide Area Network (WAN) may link together different 
LANs. A WAN typically includes packet switches, micro- ^ 
wave links, and satellite links. Thus, a network may include 
several htmdred or more interconnected devices (nodes), 
distributed across several geographical locations, and 
belonging to several organizations. 

LANs are typically used for high speed communications 
with relatively few nodes, while WANs are us6d for con- 
necting a vast nimiber of nodes, but generally at a slower 
speed. Therefore, LAN transport mechanisms and protocols 
are typically not appropriate for use on a WAN, 

FIG. 1 shows an example of an arrangement in which a 
WAN couples together several LANs. In particular, FIG. 1 
shows WAN 10 connecting LAN A, LAN B and LAN C. A 
LAN/WAN interface 12 provides translation, data 
formatting, and/or other protocol-related functions so that ^ 
source and destination computers on LAN A may interface 
with source and destination computers on LAN B and LAN 
C. Similarly, LAN/WAN interface 14 allows LAN B to be 
coupled to WAN 10, and LAN/WAN interface 16 albws 
LAN C to be coupled to WAN 10. 

One method of interfacing a LAN to a WAN is to provide 
a router-specific interface which substitutes a WAN physical 
link layer and a proprietary data link layer in each LAN data 
message, and rale-converts the LAN messages to WAN 
compatible speeds. TTien the messages may be transmitted 50 
across the WAN. A drawback to such an approach is that 
many of the high-capadty networks that provide high-speed 
commimications within the WAN are inflexible and expen- 
sive. Additionally, there is very limited network manage- 
ment and maintenance support capabilities, and very little, if 55 
any, spare signal capacity within frame stractures, in the 
WAN protocol Tbus, this technique is generally very expen- 
sive and slow. 

SONET (Synchronous Optical Network) is a standard for 
a high-capacity optical telecommunications network. It is a 60 
synchronous digital transport system intended to provide a 
more simple, economical and flexible network infrastruc- 
ture. The Phase 1 SONET standard issued in March 1988, 
and is defined in "American National Standard for 
Telecommunications-Synchronous Optical Network 65 
(SONET) Paybad Mappings", ANSI Tl,105.02-1993 draft, 
which is incorporated by reference. 



2 

SONET may also be defined as an octet-synchronous 
multiplex scheme that defines a family of standard rates and 
formats. Despite the name, SONET is not limited to optical 
litiks. Electrical specifications have been defined for single- 
mode fiber, multi-mode fiber, and CATV 75 ohm coaxial 
cable. The transmission rates are integral multiples of 
51.840 Mbps, which may be used to carry T3/E3 bit- 
synchronotis signals. The allowed multiples are ctirrently 
specified as: 





51.840 


srs-3 


155.520 


srrs-9 


466.560 


srrs-12 


622.080 


srs-18 


933.120 


STS-24 


1,244.160 


srrs-36 


1.866.240 




2.488.320 



The CCnr Synchronous Digital Hierarchy (SDH) defines a 
subset of SONET transmission rates, beginning at 155520 
Mbps, as set forth below: 



SONET SDH equivalent 

STS-3C STTM-l 

srrs-i2c srM-4 

STS^ srrM-16 



As defined, SONET can be used in loop carrier, local 
network, and long haul network application areas. 

FIG. 2 is a block diagram of SONET elements coupled 
together in a direct synchronous multiplexing mode. 
SONET line signals 21 are transmitted across the SONET 
digital cross-connect system 20. SONET terminal multiplex- 
ers 22, 24 receive tributary signals 23, for example from 
source and destination computers, and provide the SONET 
line signals. 

One advantage of the SONET standard is that individual 
tributary signals may be accessed within the structure of the 
multiplexed SONET line signal. For example, SONET add- 
drop multiplexers 26 and 28 may each provide data from 
their reqjective tributary signals 25 onto the SONET digital 
cross-connect system 20. 

The building block of the SONET protocol is a synchro- 
nous tran^ort frame 30, shown in FIG. 3. Frame 30 includes 
transport overhead 34, and synchronous payload envelope 
(SPE) 32. Although data is transported serially, the frame 30 
is typically represented by a two-dimensional map with N 
rows and M columns; a byte is provided at each row/column 
intersection. The signal bits are transmitted starting with the 
byte in the upper left hand comer of the frame 30, followed 
by the second byte in the top row, etc., until all of the bytes 
of the first top row are transmitted. The second and subse- 
quent rows follow transmission of the first row in the same 
manner. 

The SPE 32 includes individual tributary signals, and is 
designed to traverse a SONET network from end to end. The 
SPE 32 is assembled and disassembled only once, even 
though it may be transferred from one transport system to 
another (i.e., between several SONET network nodes) many 
times on its route through the SONET network. 

Some signal capacity is allowed in each frame 30 for 
transport overhead 34 to provide support and maintenance 
facDities, such as alarm monitoring, bit-error monitoring, 
and data communications channels. Transport overhead 34 
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lypicaUy pertains only to an individual Uansport system and In one embodiment, an interface is provided between a 

is not transferred when the SPE 32 is transferred between first network and a second network, mcluding a fiist inler- 

different transport systems. ^cc device, a second interface device an input bufEcr and 

One method of interfacing a LAN with a WAN, such as a control circuit. The frst "i U^rfa^ devio. cap^^r^of 

standard defined by the ^^^^^^^^^^ ^.^'^^^ deVicc is capable of communicating across the second 
specification. Each ATM cell has an overhead of 5/48 or ^^^^^^^ ^ accordance with a protocol of the second net- 
10.4%. This is a relatively large amount of overhead, when ^^^^ ^ ^^^^ ^^.^^^ ^^^^^^ ^ p^^^ 
compared to a typical LAN packet. FIG. 4 shows an ATM interface device. A control drcuil is coi^led between 

cell 40, in which 48 bytes of ATM data 44 are transmitted lO interface device and the second interface device, and 

with a 5-byte ATM header 42. In accordance with the ATM ^ coupled with the input buffer. The control circuit deler- 
standard, an ATM cell always has 53 bytes. mines a length of the packet and provides the packet and an 

FIG, 5 shows a SONET synchronous transport &ame 49 indication of the length of the packet to the second interface 
that includes ATM cells. The synchronous tran^ort frame device. The second interface device transmits the packet and 
49 inchidcs SPE 53 and a transport overhead 48 which 15 indication of the length of the packet across the second 
includes section overhead 50, pointer 52 and line overhead network. 

51. The pointer 52 is a reference which indexes the starting Another embodiment of the invention is directed to a 
point of the SPE 53. SPE 53 includes path overhead 54, method for transmitting data from a first network to a second 
ATM cells 55A, 55B, 55C, 55D, and 55E, and other data. network, comprising the steps of receiving a data packet 
During times for which there are no ATM cells to transmit, 20 ^ source on the first network, bufBering the packet to 
an idle space is provided (see for example idle ^ace 56 provide buffered data, determining a length of the padcet 
between two ATM cells 55D and 55E). In addition, because, buffered data, and transmitting the packet and an 

an integer number of ATM cells may not fit within a given indication of the length of the packet across a third network 
SPE, there may be some empty space 57 (see FIG. 5) ^hich is coupled between the first network and the second 
following the last ATM cell, or otherwise di^rsed within 25 ^^^^0^}^ ^ t^at the packet is received at the second net- 
the SPE. . work. 

FIG. 6 depicts a known process for convertmg LAN data Yet another embodiment is directed to an apparatus for 
to ATM cells for transport over a SONET network. In step transmitting data from a first network to a second network, 
58, a LAN packet is received from a first IAN. The LAN comprising means for receiving a data packet from a source 
packet is divided into 48-byte segments (step 59) m accor- 30 network, means for buffering the packet to 

dance with the fixed ATM cell size. An ATM 5-byte header _^de buffered data, means for determining a length of the 
is added to each of the 48-byie segments (step 60) to create buffered data, and means for transmitting 

a number of ATM cells. The ATM cells are packed mto a ^ indication of the length of the padcet 

SONET SPE (step 61). The appropriate SONET transport ^ ^^^^ ^^^^^j^ ^^^^ ^ ^^^^^^ 1,^.^^^^^ fij^t 

overhead is then added to the SPE (step 62) to create a 35 ^^^^^^^ ^^^^ network. 

synchronous transport frame. The frame may then be trans- ^^^^ embodiments, a receive buffer may 

mitted over the SONET-coinpatible network (step 63). ' differences between the first 

At another SONET midUple^r, Ae and second networks. Additionally, a preamble may be 

port frame is ^^^jf /"^P,^,1>'J^^^ ^ transmitted along with the data, and a fill pattern may be 

overhead IS removed (step 65) to ^ekJ the SPE. It is^ 40 j^^^t^^^ when there are no packets to be transmitted. The 
necessary to unpadc the ATM alls from ttie SPE m order to ^^^^^^ ^^^^ 

provide ATM cells (step 66). lUe ATM header is removed ^^^^^'^^^^^ ^ , contiguous data stream in a frame 

from each of the AIM cells (step 6^. Only then may the ^^^^^ ^ ^^^^^ ^ ^ ^^^^^ The packet 
LAN padcet data be reconstructed from Oie ATM ceU data transmitted by an interface device operating in a 

(step 68). Tbe reconstructed LAN padcet may then be 45 ^^^^ ^.t^. ^^de that does not require additional formatting 
transmitted onto a second LAN (step 6V). . , or encapsulation, other than that required to comply with a 

As is evident from HOS. 4^, there is a sigmficant J^^^^^^f^te n;twork over whichle padcet is transmitted, 
amount of overhead Ti^cse and other feattires and advantages of the present 

stnictedl^ data over a SONET n^^^^^ invention shall appear from the following detaHed descrip- 

standard. Has overhead includes not only signal bandwidth, 50 li^y^^^^^j*^*^ 
for example the 5-byte ATM header added for each 48 bytes drawmgs. 

of data, but also significant processing time in order to BRIEF DESCRIPTION OF THE DRAWINGS 

divide the LAN padcet, construct the ATM cells, and ulti- schematic illustration of a wide area network 

mately reconstrurt the LAN packet (WAN) connecting several local area networics (LANs); 

SUMMARY OF THE INVENTION FIG. 2 is a block diagram showing elements of a SONET 

network^ 

In a preferred embodiment of the present mvcntion^ a ^ ^ ^^^^^^ ^ synchronous transport 

method and apparati^ are provided for transmitting a pactet transmitted across a SONET network such 

of LAN data over a WAN, by retaimng a native LAN frame 

format of the packet across the WAN. Thus, data received 60 ^^^J; ^n^^. ™* 

Zm a LAN may be transmitted over a SONET point-to- FIG. 4 depicts the contents of an ATM celU 
point link withoJthe interim steps of creating AHVl cells or nC S dlustrates an approach to Pa^^^ <^^^ 
otherreformaltedmessageunits.Instead,theLANdatamay a synchronous payload envelqpe (SPE) wit^n a synchro- 
be transmitted direcdy over the SONET link as "raw data" nous transport frame such as that shown m ¥IG, 3; 
(native LAN frame format) within SONET transport frames, 65 HG. 6 is a flow diagram showing the known proce^stei» 
and reconstructed dirccUy at the receiving end of the required to d-ansmit rcfonnatled LAN data over a SONbl 
SONET link. network using the AIM standard; 
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FIG. 7 is a high-level blcxik diagram of an embodiment of between LAN A and LAN B without formatting the packet 

the invention, in which a SONET network provides com- data into separate ceUs, such as ATM cells. The point-to- 

munications between two LANs; poiat link 75 may be a SONET link within the WAN 70, 

« . V, , J- r cz-kKTCT/T AVT which is cTcated and mamtained by a communications 

FIG. 8 IS a block diagram of a SONET/LAN mtertace, ov'der 

such as that shown in HG. 7; , , ^ RG. 8 depicts more detail of the SONET/LAN interface 

FIG. 9 is a flow diagram of process steps for transmitting ^ SONET line transceiver 80 provides a physical inter- 

a LAN packet from one LAN network to another LAN face with the SONET network. Coupled to the transceiver 80 

network across a SONET network, which may be performed ^ ^ SONET framer/deframer with raw data capability 82. 

by the elements of the block diagram of FIG. 8; xhe "raw data" capability, also referred to as "native frame 

FIG. 10 illustrates more detail of one of the steps of FIG. format** capability, means that data can be transmitted across 

9, in which the LAN packet is packed direcUy into a SONET the SONET network Viathout adding additional overhead to 

synchronous payload envelope (SPE) along with a packet the data other than the overhead which is required by 

length field' SONET. Examples of overhead required by SONET include 

FIG. 11 iihistrates more detail of the one step of FIG. 9. 15 t^P^^ overhead including payload pointers. Path over- 

in which a LAN packet is unpacked from the SPE using head mcludmg section overhead and hne overhead, and 

information regarding the length of the LAN packet; vimd transport overhead mcludmg 

t. orxKTT-r 1 • A '*u virtual path overhead. In at least one SONET 

FIG. 12 shows a SONET frame in accordance with an overhead includes payload pointers, 

embodunent of the present mvention; automatic protection switching, parity check, alarm 

FIG. 13 shows a mapping of LAN packets onto SONET 20 ^Jq^^^Iq^^ section overhead includes frame alignment 

SPEs according to the invention; pattern, and STS identification, and parity check. 

FIG. 14 is a detailed schematic diagram of one apparatus When a data packet is transported in its native frame 

for implementing the invention; format, this means that the data packet is still recognizable 

FIG. 15 is a flow process diagram of steps performed by ^5 (ananged) as it was when transported across a LAN. 

the Transmit FIFO Write Control Logic (1402) of FIG. 14; Typically, this also means that diere is no additional over- 

FIG 16 is a flow process diagram of steps performed by head interspersed within the data packet. In one 

the Transmit FIFO Read Control Logic (1410) of FIG. 14; embodiment, an interface device having AIM cell process- 

• ji- f *™ ^«™-,?K., inc capability may be Operated in a mode which bypasses 

..T-'^^^^rw'^rr'^ntfr^^^ 30 thfAmcellVocessing^ability.su^ 

the Receive FIFO Wnte Control Lx,gic (1420) of HG. 14, 30 ^^^^ ^^^^^^ ^^^^ ^^^^^^^ 

FIG. 18 is a flow process diagram of steps performed by ^ ability may be invoked by selecting a test or diagnostic 

the Receive FIFO Read Control Logic (1430) of HG. 14; framer/deframer 82 (bypassing the 

FIG. 19 is a block diagram of another embodiment of the processing), 

invention; ^ ^jata formatter 84 is coupled between the framer/ 

FIG. 20 is a flow process diagram of steps performed by deframer 82 and LAN media access controller 86. The 

the apparatus illustrated in FIG. 19 when transmiuing data controller 86 provides an interface to the appropriate LAN, 

to a SONET WAN; for example LAN A or LAN B shown in FIG. 7. 

FIG. 21 is a flow process diagram of steps performed by piQ . 9 shows the process steps by which a LAN packet is 

the apparatus illustrated in FIG. 19 when receiving dau from transmitted from a first LAN to a second LAN. In step 90, 

a SONET WAN; and the LAN packet is received from the first LAN. In step 91, 

FIG. 22 is a detailed schematic diagram of one embodi- the length of the LAN packet is determined, so that ulti- 

ment of the invention as shown in FIG. 19. mately the LAN packet may be unpacked on the receiving 

end. Such packet length may be defined as a number of 

DETAILED DESCRIPTION eight-bit bytes, but may also be defined as a number of bits. 

There are many businesses or organizations having two or or a number of 16-bit words. The LAN packet may be one 

more geographically-separated LANs between which much from an ethemet, FDDI, token ring, or other protocol, hi step 

data is transmitted. FIG. 7 shows an example in which LAN 92, the LAN packet and a packet length field are packed 

A is in a first location 71, such as a first building or campus, directly into a SONET synchronous payload envelope 

and LANs B and C are in a second location 72, such as a 50 (SPE), In step 93, SONET transport overhead is appended to 

second building or campus. WAN 70 provides communica- the SONET SPE to create a synchronous transport frame. By 

tions among these and several other LANs, for example using a packet length field, it is not necessary to include 

LAN D and LAN E. In this example, LAN A is coupled to detimiters indicative of the end of packet and beginnmg of 

WAN 70 by SONET/LAN interface 73A, and LAN B is packet, which would typicaUy be inchidcd if the packet were 

coupled to WAN 70 by SONET/LAN interface 73B. LANS 55 encapsulated within another format, such as Uie HDLC 

is also coupled to LAN C by bridge 74. LANAVAN interface format. HDLC encapsulation would require significanfly 

76 provides communications between LAN D and WAN 70, more overhead. 

and LAN/WAN interface 77 provides communications Id step 95, the synchronous transport frame is transmitted 
between LAN E and WAN 70. Suitable LAN/WAN inter- over a SONET-compatible network. The synchronous trans- 
faces 76, 77 are known in the art 60 port frame is received, and the SONET transport overhead is 
The first SONET/LAN interface 73A, second SONET/ then removed (step 96) to yield the synchronous payload 
LAN interface 73B, and WAN 70 provide a point-to-point envetope SPE (step 97). Because the SPE includes a packet 
communications path 75 between LAN A and LAN B. In length field, the bytes of the LAN packet may be unpacked 
essence, tbe SONET/LAN interfaces 73A, 73B provide a from the SPE by unpacking the appropriate number of bytes 
bridge function between LAN A and LAN B, and also an 65 as determined by the packet length field (step 98). The 
effective interface between LAN A and LAN C. The unpacked LAN packet is then transmitted onto the second 
SONET/LAN interfaces 73A, 73B transmit and receive data LAN (step 99). 
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As can be seen from a comparison of FIG. 9 and FIG. 6, 
there is much less overhead and many less steps in the 
present invention, as compared with the ATM approach. 
Because there is no fragmentation of the original packet, 
except perhaps between successive SPEs, higher transfer 5 
rates are achievable while using less computer resources and 
costs. Thus, transmitting a LAN data packet as a contiguous 
data stream contributes to more efficient communications. 

FIG. 10 shows more detail of an exemplary embodiment 
of step 92 of FIG. 9, in which the LAN packet is packed 
directly into a synchronous payload envelope. In step 100, a 
SONET framer/deframer is controlled to communicate in a 
raw data mode. In step 101, the native preamble for a first 
LAN packet is packed into a SPE, followed by a packet 
length field for the first packet (step 102). Then, the data for ^5 
the first LAN packet is packed (step 103). If there are no 
more LAN packets available at this time, a fill pattern is 
packed into the SPE and subsequent SPEs, until a next LAN 
packet is available (step 104). The fill pattern may be 
selected to be easily distinguishable from a LAN preamble, 20 
as will be discussed in more detail below. Once a next LAN 
packet is available, the preamble is packed (step 105), the 
packet length field is packed (step 106), and the next LAN 
packet data is packed (step 107). 

FIG. U is an exemplary embodiment of step 98 of FIG. 2s 
9, in which a LAN packet is unpacked from a synchronous 
payload envelope using information regarding the packet 
length. Because the SONET framer/deframer is operating in 
a raw data mode, there may not be a specific signal indi- 
cating that a new packet is being received Therefore, in one 30 
embodiment of the invention, a native preamble is detected 
within the raw data that is received from the SONET 
framer/deframer (step 108). This preamble detection is usu- 
ally performed by a device that is external to the SONET 
framer/deframer, so that the SONET framer/deframer is free 35 
to continue receiving the stream of raw daU. Generally, a 
native (LAN) preamble includes alternating ones and zeros 
transmitted serially, but it is possil)le to use other sequences. 
After the preamble has been detected, the packet length field 
is provided from the SONET framer/deframer. Accordingly, 40 
in step 109, the packet length field is checked to determine 
the number of bytes in the LAN packet. Once the number of 
bytes in the LAN packet is known, the bytes may be 
provided to a LAN interface device (step 110). If a subse- 
quent LAN packet is not transmitted immediately after a 45 
previous LAN packet, then a fill pattern may be received 
from the SONET framer/deframer until a next preamble is 
detected (step 111). 

FIG. 12 shows one approach to formatting a variable 
length LAN packet into a modified form for direct trans- 50 
mission as raw data over a SONET network. The modified 
packet 115 includes a LAN preamble 116, packet length field 
117, and variable length LAN data packet 118. In one 
embodiment, the preamble inchides 8 bytes, the packet 
length fieU includes 2 bytes, and the variable length LAN S5 
data packet may include any nuimber of bytes as determined 
by the packet length field 117. 

FIG. 13 shows an example of how several modified LAN 
packets may be transmitted across a SONET network using 
- ..a number of SPEs. For example, the SONET data stream 60 
may include a first synchronous transport frame 120, that 
includes a first SPE 121. The first SPE 121 includes path 
overhead 122 and data 123; data 123 is a combination of 
LAN daU and fiU daU. For example, the first SPE 121 may 
include a first modified LAN packet 130, which is followed 65 
by fill data 131. This is an example of a case in which there 
was no data to transmit from a first LAN to a second LAN 



from the time that the first LAN packet 130 was sent untU 
a second LAN packet is received. Following the fill data 131 
is a second modified LAN packet 132, which is immediately 
followed by third modified LAN packet 133. In this 
example, because the third modified LAN packet 153 does 
not fit within the space still available in the SPE 121, only 
a first portion 133A of the third modified LAN packet is 
included within SPE 121. 



Following the first synchronous transport frame 120 is a 
second synchronous transport frame 124, which includes a 
SPE 125 having path overhead 126 and data 127. The second 
SPE 125 includes a second portion 133B of the third 
modified LAN packet 133. No additional overhead is 
required to define this split between the first portion 133A 
and the second portion 133B becaxise in the beginning of 
each modified LAN packet is the packet length field 117, 
which determines the length of the variable length LAN 
packet to follow. Thus, when the raw data is provided from 
the SONET framer/deframer, all that is required is to count 
the appropriate number of bytes to folkiw, even if these 
bytes are overlaid on two different synchronous payload 
envelopes, as shown in the example depicted in FIG. 13. 
Following the third modified LAN packet 133 is a fourth 
modified LAN packet 134. 

FIG. 14 is a detailed illustration of a SONET/LAN 
interfece 73. In this embodiment, a "LAN to Raw Data/ 
Framer" (LRDFRMR) 140 provides an interface between a 
"Switched LAN Media Access Controller'* (SLMAC) 142 
and a "Raw DaU to SONETFramcr" (RDSFRMR) 143. The 
RDSFRMR 143 is further coupled to a "ParaUeWSerial and 
Serial/Parallel Converter with Clock Synthesizer'' 145, 
which is further coupled to "Fiber Optic Transceiver" 146 
and "Reference Qock" 147. The transceiver 146 interfaces 
with a SONET network 138, while the SLMAC 142 inter- 
faces with a LAN 139. Additionally, 'Host Processor*^ 144 
provides control functions to coordinate the functionality of 
several of the elements of FIG. 14. 

In this embodiment, the RDSFRMR 143 is a 622 Mbits/ 
sec SONET Framer, Part No. PM5355, available from 
PMC-Sierra, Bumaby, British Columbia, Canada; the LRD- 
FRMR is a 20K field programmable gate array. Part No. 
A32200BX, available from Actel, Sunnyvale, Calif., U.S A.; 
the Converter 145 is Part No. VCS8110, available from 
Vitesse, Camarillo, Calif.. U.SA.; and the Fiber Optic 
Transceiver 146 is Part No. HFBR5207, available from 
Hewlett-Packard, BurUngton, Mass., U.S.A. The Host Pro- 
cessor 144 may be any general purpose processor, and the 
SLMAC 142 may be any device which provides appropriate 
interface with a LAN. 

The LRDFRMR 140 may also be implemented as a 
processor, any combination of firmware or software, or may 
be embodied as an ASIC or combination of discrete ele- 
ments. The components of the LRDFRMR 140 depicted in 
FIG. 14 are described below. 

The Transmit FIFO Write Control Logic 1402 provides an 
interface with SLMAC 142 when daU has been received 
from the LAN 139 by SLMAC 142. In particular, Trananit 
FIFO Write Control Logic 1402 interfaces with a Transmit 
Packet Size Counter 1404 and a Tranmit FIFO 1406. The 
Transmit FIFO Write Control Logic 1402 utilizes a clock 
emanating from a Qock Buffer 1408, which receives clock 
signals from SLMAC 142. 

The Transmit FIFO Read Control Logic 1410 provides 
data, that has been previously processed by the Transmit 
FIFO Write Control Logic 1402, to the RDSFRMR 143. 
Such data may be particularly provided by Transmit Register 
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1412 Multiplexer 1414 selects specific data from the Trails- (Transmit FIFO Not FuU). During this time, the periodic 

mit FIFO wSrand Multiplexer 1416 selects either data transmit pulse is contmuaUy ^"i^' ''yj:^'^^^^^ 

the TVansiit FIFO 1^6 . fiU pattern data from «,e PJXji^Zt^u^to'^e^ffit dr^S 

Fill Pattern Data Generator 1418. the Transmit RFO 1406 is transferred to the RDSFRMR 143 

The Receive FIFO Write Control Logic 1420 provides Multiplexers 1414, 1416, and Transmit Register 

control when data is received from the SONET network via ^^^2. 

the RDSFRMR 143. In particular, the Receive FIFO Write During step 162. status bits of the Transmit FIFO 1406 arc 
Control Logic 1420 controls the Preamble Detect Logic monitored to determine the end of the packet as indicated by 
1422, the Receive FIFO 1424, and the Receive Packet Size ^.^^^^ ENDOFPKT. Additionally, during step 162, the peri- 
Counter 1426. odic transmit pulse is also generated, step 163, to maintain 

The Receive FIFO Read Control Logic 1430 then controls the RDSFRMR 143 mnning in the raw data mode. At the end 

the Receive FIFO 1424, and the Receive Register 1432, to the padcet, the Transmit FIFO Read Control Logic 1410 

provide the received data to SLMAC 142. checks to see if any transmit errors occurred (step 164). If no 

Exemplary operation of the structure depicted in FIG. 14 errors occuned, then the last word of the data packet is seiit 

will be explained with respect to operation of each of the to the RDSFRMR (step 165). If there is an error, the fill 

Control Logic Elements 1402. 1410, 1420, and 1430. In pattern from the Fill Pattern Generator 1418 is sent to the 

particular FIG. 15 is a flow process diagram of steps RDSFRMR 143, as shown in step 166. After the final word 

performed by the Transmit FIFO Write Control Logic 1402. is written in either step 165 or 166, then the process retur^ 

The process begins by waiting for the SLMAC 142 to start to step 161 which provides a fill pattern to the RDSFRMR 

a data transfer (step 150), This may be determined as an 143. 

initial state, by providing a reset signal. Upon receipt of a piG. 17 illustrates the process steps performed by the 

Transmit Enable Signal (TXEN) ftom the SLMAC 142, the Receive FIFO Write Control Logic 1420, to receive data 

Transmit FIFO Write Control Logic 1402 begins to load the from the SONET network via RDSFRMR 143. The process 
data received from the LAN into the Transmit FIFO 1406. ^ begins when the RDSFRMR 143 provides an indication that 

step 151 In one embodiment, the SLMAC 142 also provides it has data. For example, this may be indicated by the 

an indication of the packet size of the LAN packet. assertion of a Receive FIFO Not Empty Flag Signal 

Accordingly, in step 152, the packet size word received from (RFFNempL). At this point, as shown in step 170, data is 

the SLMAC 142 is loaded mlo the Transmit Packet Size ^ad from the RDSFRMR 143. In step 171, the Preamble 
Counter 1404. Alternatively, the packet length of a LAN ^ Detect Logic 1422 monitors the sequence of data being read 

packet may also be determined within the LRDFRMR 140. to determine whether there is a preamble. If a preamble is 

In step 153 the Transmit Packet Size Counter 1404 is not detected, then data may simply be discarded as shown m 

decremented ^e data is written to the Transmit FIFO step 172. If, however, there is a preamble detected, then the 

1406 Such operation would typically continue until the process proceeds to step 173 m which the preamble is loaded 
packet count reaches zero, indicated by PKT CNT-^. 35 into the Receive FIFO 1424. AdditionaUy, tte packe^^ 

However if there is a transmit error, or if the Transmit FIFO word, previously referred to as Packet Ungtii Field U7 is 

becomes foil, the process may proceed to step 154 in which loaded into the Receive FIFO 1424, as well as the Padcet 

an Error Latch is set. Then, if the Transmit FIFO is fiiU, step Size Counter 1426, step 174. 

155 shows that data is written even though ihc Transmit in step 175, the words of the data received froin the 
FIFO 1406 is full. In one embodiment, the data is actually 40 RDSFRMR 143 are toaded into the Receive FIFO 1424 

discarded in step 155. From step 155, if the Transmit FIFO while decrementing the contents of tiie Packet Size Counter 

1406 is not still full, then the process can proceed to step 153 1426 and monitoring if it has expired to a count of zero, 

again. Alternatively, if the packet count reaches zero prior to which indicates the end of the packet has been reached. In 

the Transmit FIFO 1406 becoming full, than the process this example, the data is received from the RDSFRMR 143 
proceeds to step 156. 45 as 16-bit words. Various eaor indications may also be 

In step 156, the Transmit Error Utch (TXER) is accessed monitored during step 175. For example, any error fla^ 

todete^e;hethertherewasatransmiterror.Iftherewas provided by the RDSFRMR V J>^_7^^^^°^^^ 

noerror then in step 157, two bits of the Transmit FIFO may AdditionaUy, the Receive FIFO Empty Flag of the RDS- 

br^ to the data transfer was successful. FRMR may be monitored O^^P^^^^l"^ ^^^k 
Stemativd^^there was a transmit error, then two bits 50 flagof the Receive FIFO 1424 (RXFFflag). If either 0^^^^^^ 

from the Transmit FIFO may be set to indicate that an error FIFO flags are set, tiien the process may procfed to step 176, 

occurred, step 158. After either step 157 or step 158, the in which a Receive Error Utch is set, and t^^^^^^^^^P 

cmbodnnent of the Transmit ' checked to detem^ whether an eiror has occurred (step 

1410. FoUowmg a ^.^y^f^f^T^'^S^ Tw) K no error has occurred, then the last word may be 

SSsSfO iSmoSitored lo^determine whether FIFO Read Control U,gic 1430. ImUally, as shown m aep 
JSTiSedbyanassertionbysignalTXFFNEFL 181. the process is idle until a srgnal ts received mdtcaUng 
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that the Receive FIFO is not empty (RXFFNEMPL). Once 
such a signal is received, in step 182, a signal may be 
provided to the SLMAC 142 to indicate that there is valid 
data which is being received from the RDSFRMR 143 by the 
LRDFRMR 140. In the example shown in FIG. 14, this is the 5 
Signal RXDV Also, during step 182, the data which is in the 
Receive FIFO 1424 is provided to the SLMAC 142 via the 
Receive Register 1432. As indicted with respect to FIG. 17, 
the Receive FIFO 1424 may contain error bits indicating 
whether an error has occurred during the reception of data lO 
from the RDSFRMR 143. Accordingly, these error bits are 
checked in step 184. If there is no error, than in step 185 the 
final word of the data packet is sent to the SLMAC. 
Alternatively, if there was an error bit set, then a fill pattern 
may instead ,be sent to the SLMAC and a Receive Error 15 
Signal may be inserted (RXER) to the SLMAC 142, as 
shown in step 186. Following either step 185 or 195, the 
Receive Data Valid Signal RXDV may be deasserted. 

As described above, some SONET Frameis/Dcframers 
may provide a native format transmit capability, as well as 20 
other transmit capabilities (e.g., ATM cell firaming). In a 
particular embodiment that implements the SONET Framcr/ 
Deframer as PMC-Sierra Part No. PM5355, an option is 
provided in which ATM cell processing is disabled and raw 
data is either inserted or extracted to or from the SONET 25 
payload. To use the PM5355 in this mode, several register 
bits may be set to the respective values shown below: 



Bits 


Rcg.# 


Register Name 


\felue 


CDDIS 


0x5C 


RACP GFC/Misc Control 


1 


HCSADD 


0x50 


RACa? Control 


0 


HCSPASS 


0x50 


RAOP Control 


1 


HCSB 


0x60 


TACP Control 


1 


HCSADD 


0x60 


TACP Control 


0 


HCSPASS 


0x60 


TACP Control 


1 


PASS 


0x50 


RAOP Control 


1 



30 



35 



Such functionality may also be designed into a single ^ 
ASIC which encompasses the functionality of the RDS- 
FRMR 143 and the LRDFRMR 140 shown in FIG. 14. 
Similarly, the functions described above may be allocated to 
any of several architectural elements and combinations of 
hardware, software and firmware. For example, all or any 45 
portion of the functionality described with re^tect to FIG. 14 
may be implemented as a general purpose processor which 
runs software to provide such ftinctionality. 

FIG. 19 illustrates another embodiment of the invention, 
in which a data framer 192 determines the packet size of a 50 
packet to be transmitted, so that this function need not be 
performed by a media access controller. As with the earlier 
examples, the packet size may be defined in one embodi- 
ment as a number of bytes. As illustrated in FIG. 19, the data 
&amer 192 also provides synchronization between a SONET 55 
framer/deframer 191 and a media access controller 193, so 
that these two devices may operate asynchronously and at 
different speeds. 

FIG. 19 depicts more detail of this alternative SONET/ 
LAN INTERFACE 73' (similar to interface 73 ia HG. 8). A 60 
SONET line transceiver 190 provides a physical interface 
with the SONET networic. Coupled to the transceiver 190 is 
a SONET fi-amer/deframer 191. At the opposite end, a LAN 
media access controller (MAC) 193 has one interface 
coupled to the LAN, "LAN to raw data framer" 65 
(LRDFRMR) 192 provides the interface between the framer/ 
deframer 191 and the MAC controller 193. 
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In this embodiment, LRDFRMR 192 includes a transmit 
buffer 194 and transmit packet size control module 195. The 
control module 195 receives a LAN packet from MAC 
controller 193, and transmits the packet to buffer 194 where 
it is stored. The control module 195 determines the size of 
the LAN packet once it has been completely stored in buffer 
194. Such a feature eliminates a need for the MAC controller 
193 to determine the size of the LAN packet and to append 
the packet length field to the LAN packet. LRDFRMR 192 
also includes a receive buffer 196 that receives SONET 
packets from the SONET framcr/dcfiramer 191, via receive 
synchronization module 197. In the event that the SONET 
firamer/deframer 191 and the MAC controller 193 operate 
asynchronously or at different speeds, the receive buffer 196 
stores at least a portion of the SONET packet prior to it being 
passed to the MAC controller 193, so that module 197 may 
provide the received packet at the appropriate speed and 
time to the MAC controller 193. 

FIG. 20 is a process flow diagram of transmit mode 
operation of LRDFRMR 192. In step 201, LRDFRMR 192 
begins receipt of a LAN packet from the MAC controller 
193. In step 202, Lm)FRMR 192 begins storage of the LAN 
packet into the transmit buffer 194. While the LAN packet 
is being stored in buffer 194, a coimter is incremented (step 
203). In one embodiment, MAC controller 193 generates a 
transmit enable signal TXEN while sending the LAN packet. 
While this signal is asserted data from the MAC 193 is 
stored in the buffer 194, and the control module 195 incre- 
ments the counter to monitor the size of the LAN packet 
being stored. Once the LAN packet has been completely 
stored in buffer 194 (which may be indicated by the TXEN 
signal being dc-asserted), the counter value may be used as 
the packet length (step 204). Once the packet length has 
been determined, a preamble, packet length and the LAN 
packet data itself may be transmitted to the SONET framer/ 
deframer 191 (step 205). 

Operation in the receive mode of the LRDFRMR 192 is 
illustrated in FIG. 21, In step 210, the receive synchroniza- 
tion module 197 detects a SONET packet in the raw data that 
is received from the SONET framer/deframer 191. In one 
embodiment, the SONET data rate is 155,52 bits/sec, which 
yields an effective rate of 19.44 Mbytes/sec at a continuous 
rate. However, the effective data rate which an exemplary 
MAC controller may receive data is only 12.5 Mbytes/sec. 
Therefore, it may be advantageous to provide a buffering 
mechanism such as buffer 196 to allow for this data rate 
difference. Thus, in step 210. the SONET packet in the raw 
data is received from the SONET framer/deframer 191 at a 
first data rate. In step 212, the receive synchronization 
module 197 begins storing the packet in the receive buffer 
196 as the data is being received from the SONET framer 
191. As with earlier embodiments, the detection of the 
packet may be performed by a preamble detector. In step 
214, the synchronization module 197 transfers data from the 
receive buffer 196 to the MAC controller 193 at a second 
data rate that is compatible with the MAC controller 193, 
until all of the packet is transmitted. 

Id one illustrative embodiment, the SONET framer/ 
deframer 191 is a PMC Sierra device (Part No. PM5347), 
each of the transmit buffer 194 and the receive buffer 196 is 
a 4Kx8 First In, First Out (FIFO), and the traiismit packet 
size control module 195 and the receive synchronization 
module 197 are both implemented within an Actel one-time 
field programmable gate array (FPGA) with 20,000 gates 
(Part No. 32200 DX-1). With FIFOs of this size, this 
embodiment can support packet lengths of 4096 bytes of 
Fast Ethernet packets (100 M/by tes/sec) over a SONET STS 
3-C fiber at 155 Mbytes/sec. 
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FIG. 22 is a detailed illustration of the alternative 
SONET/LAN interface 73'; in particular, detail is provided 
regarding a FPGAor ASIC (Application Specific Integrated 
Circuit) embodiment of the transmit packet size control 
module 195 and the receive synchronization module 197 of 
FIG. 19. 

In this embodiment, an ASIC 22D provides an mterface 
between a MAC controller 222, which is also coupled to a 
LAN 221. and a "Raw Data to SONET Framer" 
(RDSFRMR) 223. The ASIC 220 referred to herein may be 
implemented as an FPGA or an ASIC, or as a combination 
of discrete devices. In at least one embodiment it is imple- 
mented as a one-time programmable FPGA. In another 
embodiment, it is implemented as a re-programmable FPGA 
and is further coupled to a non-volatile memory device and 
circuitry to program the re-programmable FPGA from the 
memory device upon power up of the circuit. 

The RDSFRMR 223 is further coupled to a fiber optic 
transceiver 224, which provides an interface to the SONET 
network 218. A reference clock 225 is also coupled to the 
RDSFRMR 223, and provides a 19.44 MHz reference. 
Additionally, a second reference clock 226 provides a 25 
MHz reference to the ASIC 220. In this embodiment, a 4Kx8 
transmit FIFO (TXFIFO 227) provides the functions of the 
transmit buffer 194 of ¥IG. 19, and a 4Kx8 receives FIFO 
(RXFIFO 228) provides the functions of the receive buffer 
196 from FIG. 19. 

As with earlier embodiments, the functionality shown in 
FIG. 19 may alternatively be provided by discrete circuitry, 
by software modules operating on a general purpose or a 30 
special purpose computer, or any combination thereof. 

In operation, a "/^-bil Converter 229 within ASIC 220 
receives LAN packets from the MAC controller 222, and 
provides this data through the Multiplexer TXWRDPMUX 
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In the receive mode, preamble detect logic 250 detects 
that a preamble has been received by comparing the incom- 
ing data with a known preamble value, and detects that a 
start of a packet has been received by comparing the 
incoming data with a known Start Of Field (SOF) delimiter 
value. Preamble register REG 1 (251) stores the known 
preamble value (e.g., 55H) and preamble register REG 2 
(252) stores the known SOF value delimiter (e.g., SDH), so 
that the preamble detect logic can access these registers for 
these known vahies. The preamble detect logic also activates 
the receive write (RX WR) state machine 253. Tbe padcel 
length field, v^^ich typically follows the SOF delimiter, is 
stored in a receive write (RX WR) counter 254, which data 
may also be provided to the RX WR sUte machine 253. 

The packet data is stored in the receive FIFO 228 via 
register REG 8 (255), multiplexer MUX 3 (256), and 
register REG 9 (257). Once there is data in the receive FIFO 
228, the receive read (RX RD) counter 258 controls the 
receive FIFO 228 to provide the receive packet daU to the 
MAC 222 via register REG 10 (259), multiplexer MUX 4 
(260), register REG 11 (261), multiplexer MUX 5 (262), and 
register REG 12 (263). The RX RD counter 258 may also 
control MUX 4 (260) to provide the preamble from pre- 
amble REG 1 (251) and the SOF delimiter from preamble 
REG 2 (252). Register REG 11 (261), together with multi- 
plexer MUX 5 (262), provides a translation from 8-bit bytes 
to 4-bit mT)bles. 

As indicated in FIG. 22, various registers and additional 
inputs 00 many of the multiplexers may be used in combi- 
nation to provide diagnostic capabiUty for various segments 
of the ASIC 220. 

Having thus described at least one illustrative embodi- 
ment of the invention, various modifications and improve- 



provides this data tnrougn me muiupioAoi ir>.r^E^M^ itxw. ^^^^ readily occur to those skilled in the art and are 
230 and register REG 1 (231) to the trananit FIFO 22h 35 -^^^^^^^ 5^ ^^hin the scope of the invention, 
While the packet is being loaded, the transmit nght CTX ^^rdingly, the foregoing description is by way of example 



40 



45 



WR) state machine 232 controls a 16-bit counter 233 to 
increment while the packet is still being stored (i.e., while 
transmit enable TXEN is asserted). The Vs-bit Converter 229 
also translates the 4-bit nibbles received from MAC con- 
troller 222 into 8-bit bytes using register A (234), register B 
(235), and input register INREG (236). Once the data is 
loaded, the value in the 16-bit counter 233 is stored in a 
packet count queue FIFO 237, and also in the transmit read 
(TX RD) state machine 238 which controls the transmit 
FIFO input register (TXFIFOIN) 239 to provide synchro- 
nization between the trananil FIFO 227 and the RDSFRMR 
223. Additionally, register REG 3 (240) stores the value 
indicative of the packet length, so that a packet length field 
may be provided to the RDSFRMR through the MUX 1 
(241) and transmit FIFO output register (TX FIFOOUT 
REG) 242. Multiplexer MUX 1 (241) also provides the 
packet data from the transmit FIFO 227 via the transmit 
FIFO input register 239 and also provides a fill pattern firom 
the fill pattern register 243 when desirable. 

Additionally, if an error is detected in the data stored in 
the trananit FIFO 242, then a bit may be set in a transmit 
error register (TXERR REG) 244, which in turn controls the 
mult^lexer MUX 1 (241), to receive inverted data for the 
last byte of the packet data, which will in turn cause a CRC 60 
error when the packet is ultimately received. 

Once the TX RD down counter 245 has reached a value 
of zero, the TX RD state machine 238 deteraiines that the 
transfer FIFO 227 has been emptied. The transmit receive 
(TX-RX) pulse generator 246 provides signals which in one 
embodiment controls light emitting diodes (LEDs) to indi- 
cate that data is being either transmitted or received. 
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Accordingly, the foregoing description is by way of example 
only, and not intended to be limiting. 
What is claimed is: 

1. An apparaUis for transmitting data in packets having a 
first format dictated by a first protocol from a first network 
to a second network, comprising: 

means for receiving a first packet of daU in the first format 
from a source on the first network, the first packet of 
data having a variable length; 

means for translating the first packet to a second packet of 
data which is a synchronous transport frame by directly 
inserting the first packet of data in the first format and 
a length of the first packet into the second packet of 
data; and 

means for transmitting the second packet across a third 
network which is a SONET network and is coupled 
between the first network and the second network, so 
that the second packet is received at the second net- 
work. 

2. The apparatus of claim 1, wherein: 

the first network is a local area network; and 
the means for receiving includes means for receiving the 
first packet from the local area network in a frame 
format which is native to the local area network. 

3. The apparatus of claim 1, further comprising means for 
buffering the first packet of data to provide buffered data and 
means for determining the length of the first packet based 
upon the buffered data. 

4. The apparatus of claim 1, wherein there is a transmis- 
sion rate difference between the first and second networks 
and further comprising: 
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second means for receiving a third packet of daia from a 8, The method of claim 6, further comprising a step of 

source on the second network; determining a packet length of the vanable length packet, 

means for buffering the third packet to account for the rate 9. The method of claim 8, wherein the step of determining 

difference; and ' the packet length includes receiving and stormg the vanable 
second means for transmitting the third packet to a ^ length packet in an input buffer. 

destination on the first network over the second net- IQ. The method of claim 6, wherein there is a transmission 

work. rate difference between the first and second networks and 

5. The apparatus of claim 1, wherein the means for farther comprising a step of receiving the packet from the 

transmitting includes means for transmitting a fill pattern network at a first rate and wherein the step of trans- 

across the third network when no packets are received from ^.^^^ ^ ^^^^ 

r«S;ter.in,plemented a.ett.od for transmitting ^fj^^in.^ 10. v*e.i. sUp tr^- 

pa^^ dm revived from a firs, network in a native LAN nuttmg mcludes a f «P f J^^^ ™S 

format across a second network in a synchronous transport network to account for the rate difference, 
frame, the frame including a tran^rt overhead and a " 12. The method of daim 10, further compnsmg a step of: 

synchronous payload envelope (SPE), the method compris- transmitting the synchronous transport frame to a desti- 

ing the step o£ nation on a third network over the second netwoik. 

transmitting a variable length packet received from the method of daim 6, further comprising the step of 
first network over the second network in the synchro- ^ ^cejvjjjg the synchronous transfer frame at a third network, 

nous transport frame, where the SPE of the syncto- ^^^^ ^^^j^^ receiving 

nous transport frame further mdudes a padcet lengh j^^j^^^^^ j extracting the variable length padcet from 

field and the variable length packet m the native LAN ^^^^^^J^ uansport frame. 
7.Scthodofdaim6,themetbodfurther«>mprising ^ 15. TTe method of claim 13. wherein the third network is 

a a step of transmitting a fill pattern when there are no a LAN. 
oendine frames to be sent in the synchronous transport 

K ^ ♦ ♦ ♦ ♦ * 

frame. 
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